ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group00a.txt/000099_icon-group-sender _Wed May 17 07:40:50 2000.msg

Internet Message Format | 2001-01-03 | 6KB

Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00658
    for icon-group-addresses; Wed, 17 May 2000 07:40:36 -0700 (MST)
Message-Id: <[e-mail]>
From: "Ian Trudel" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: Wed, 17 May 2000 05:26:27 GMT
X-Complaints-To: [e-mail]
X-Trace: carnaval.risq.qc.ca 958541187 24.226.208.172 (Wed, 17 May 2000 01:26:27 EDT)
To: [e-mail]
Errors-To: [e-mail]
Status: RO

"Marc Espie" <[e-mail]> a �crit dans le message news:
8ft0ri$5ao$[e-mail]...
> In article <7xnU4.786$[e-mail]>,
> Ian Trudel <[e-mail]> wrote:
> >Yes, but there are many factors that may not be in favor of doing
primitive
> >types in Icon. Speed issue may be a problem. Or when the primitive uses
> >system depend things, such as sockets or some database API. Yet, the
spirit
> >of Icon is not "everything should be made in Icon" such as Smalltalk
> >communities. Icon is not even bootstrapped. This latter made me
surprised,
> >Icon is so powerful and his text processing feature would just let anyone
> >write good, complete and yet understandable compiler/interpreter!
> I've always been under the impression that the Icon project has a shortage
> of man power, which means that many cool things actually don't exist.

Well, yet I just mean things that already exist.. but maybe Icon can help us
to do these in some easier manners?! ::)

> Personally, I would love to see Icon extended to be Idol (without the
> preprocessing, which makes things awkward enough to debug for me that I
> seldom use idol), or I would love to see the icon compiler resurrected,
and
> extended to handle separate compilation and direct translation to C
> primitive numeric types (well, C++ looks like a more viable alternative,
> but then I'm weird).

My feeling about Idol is: this is just the same as C and Objective-C. Having
Idol implemented in the core of Icon's implementation may not be trivial
task at all. I don't know Idol, but Objective-C allows many dynamic things
that you just couldn't do in C++. If Idol does so, it makes the full C
implementation harder to write. Since I haven't tried Idol, I can't speak
with much concern, but it may just be matter of changing few things out the
current preprocessing implementation to make it stronger. Yet, you could
also build a special debugging tool.

I'm some C fellow, but I'm just thinking as an Icon programmer, we should
get out of any direct contact with C. Hence I'm getting interest in some
bootstrapping, writting primitives in Icon (which they would be translated
in C for compilation and linking). If Icon would allow us to write shared
library, that'd really rocks. We could write some high level primitives that
really needs to be written in Icon (only few cases, IMO). Unfortunatly,
handling shared library is often OS-oriented. Under *NIX, it's pretty easy,
but under Windows and OS/2, it requires some special structure. Anyway, this
is just a thought!

As you write about C++, I don't see any point of it. Icon is implemented in
C and C is available on a *lot* of platforms and works quite same (I've got
a weird feeling "quite same", "quite same", [..]). You should not forget
that the interface with generated code and Icon would probably be in C
rather than C++ anyway. I think the standard translator should translate
Icon to C, but nothing says there should not be a C++ translator available
as well.

BTW, I just like your "icon compiler resurrected" ! It's an interesting
thing that talks by itself. Actually, the current Icon implementation is a
little bit complex. I've seen worst, of course, Icon is nonetheless clearly
written. But since I'm some VM hacker wannabe (*LOL*), I got in touch with
some implementations out there. Smalltalk's VM came up the easiest one.
Squeak in particular is bringing a new vision of VM implementations.
Squeak's VM is pretty easy to understand, even for a newbie VM hacker. I
don't think it should remplace Icon. I'm not promoting Smalltalk here. I
just think it could help to reimplement Icon in a new, fresh, and very
simple manner. For exemple, block contexts in Smalltalk are just the same as
"scanning environment", but they are not specific to strings, not specific
at all! This would be a long term project that IPG would probably not want
to do. However, the dynamic primitive data types would be much more
interesting and smaller project.

> Unfortunately, I don't believe that the projet has resources to do that,
> and I also know that I'm tangled up in enough programming projects that
> I can't afford yet another one :(

I don't know the position of IPG in the moment, they'll probably hook on our
thread this week. I don't know if I would do it myself, I'm kinda concerned
in professional development and willing to write software(s) in Icon. The
fact is I need something to pay my university fees. ::) Another fact is, if
I would do it.. will IPG integrate it to Icon? If the answer is no, I would
not even write a line of code because this would lead to ANOTHER dialect of
the language. I'd rather support fully Icon.

cheer,
--
Ian Trudel, aka BackOrder
StarTrip Server Administrator
http://startrip.gene6.com/